Hi @vulinh64

Apologies for the delay, and thank you for raising the PR!!

Modifying withClaim(String, List<?>) with withClaim(String, Collection<?>) is technically a breaking change for anyone who rely on the existing method signature.

In addition, our current serialization logic (ClaimsSerializer & PayloadSerializer) explicitly checks for List instances. Allowing arbitrary Collection types (e.g. Set, Queue) would either bypass our custom serialization path or introduce implementation-dependent behavior, which is not something we intend to support at this time.

That said, it would be helpful if you could share the concrete use case that requires this change, so we can better evaluate the impact and possible alternatives.

Thank you

Hi @tanya732 , thanks for replying to my comment.

The use case I had a year ago was issuing a JWT where I often made queries to the database to retrieve the user’s roles. These are, most of the time, stored as a JPA Set, and I usually didn’t care about the order of the roles. Because of that, I wished for a more “flexible” way to create a JWT claim with collection types where the order does not matter.

That being said, I wasn’t aware that this method is used by other classes. If possible, I’ll refactor this into a new overloaded method and wrap the input collection with Collections.unmodifiableList().